這系列測了快一個月的 Skill，Day 30 換個角度：不測一個做事情的 Skill，測做 Skill 本身的那個 Skill。skill-creator 是官方工具，功能是幫忙做一個新的 Skill、改一個舊的、或是幫既有 Skill 跑測試看有沒有變好。如果手上的 Skill 已經累積到一定數量，想確認某個新寫的到底有沒有用，用的大概就是這個。它的文件裡藏了一套很具體的規範：測試結果要怎麼命名目錄、評分檔要用哪幾個固定的欄位名稱，連哪種需求該不該先問清楚才動手都寫得很明確。這些細節正好可以拿來做這系列最後一次測試。

一句話含糊，它會先停下來問

丟一句很模糊的「我要做一個 skill」，它沒有直接動手，而是先回了一串問題：這個 Skill 要做什麼、什麼情境該觸發、什麼情境長得像但不該觸發、產出格式是什麼、要不要做測試、放在哪裡。這跟它文件裡寫的「先問清楚再動手」完全對得上。

一句話講清楚，它反而不走這條路了

接著把同一件事講清楚：要做什麼 Skill、觸發情境是什麼、不該觸發的情境是什麼、產出格式、要不要做測試、放哪裡，六件事一次講完，還附上一句「不用再問我，直接做」。這次它沒有照文件裡那套「先訪談」的流程走，直接跳過，自己去翻了官方那份 Skill 的參考文件，把裡面規定的評分檔欄位名稱、測試結果的目錄命名方式，一字不漏地抄進產出裡。

更意外的是：另外跑一份完全擋掉「用 Skill」這個動作的對照組，結果幾乎一樣。擋掉的那份一樣翻出了同一份參考文件，一樣把目錄命名和評分欄位寫對。擋掉的只是「正式呼叫」這個動作，沒擋掉它知道有這份文件存在、也沒擋掉它直接去讀檔案的能力——對一個本質上就是一堆放在磁碟上的檔案的工具來說，這兩者本來就是分得開的。

兩邊各自讀到了同一個對不上的地方

更值得注意的是，兩份產出都各自指出了同一件事：這個官方工具自己的說明文件，寫的測試結果存放路徑，跟它自己拿來統計分數的腳本實際要找的路徑，中間差了一層目錄。文件寫的路徑少了一層，照著文件做會讓統計腳本找不到結果。對照官方腳本的原始碼，這個落差真的存在。兩邊是各自發現、各自寫進產出裡的，不是其中一邊抄另一邊。

這對實際用途的意義

如果打算靠這類工具幫忙管理一批 Skill，值得記住的是：一句話講得夠不夠具體，會決定它走「先問清楚」還是「直接動手去查規範」這兩條完全不同的路，而不是單純「有沒有用這個工具」。而這系列反覆在問的那個問題——「用不用某個 Skill，差別在哪」——到了像這種本質是一份檔案庫的工具，答案可能是：差別沒有想像中大，只要有基本的讀檔能力，該查的東西它多半會自己去查。

三十天下來

這系列從頭到尾都在用同一個做法量不同的 Skill：拿它自己講的承諾，設計一個會逼它表態的情境，跑一次有用跟沒用的對照，再對照原始碼或實際輸出確認是真的還是看起來像真的。量出來的結果每天都不一樣——有時候差別很大，有時候兩邊幾乎一樣，有時候差別根本不在「找不找得到問題」，是在「要不要把問題寫進報告」。三十天加起來，這大概是測這類工具最老實的方式：不猜它應該怎麼樣，去看它實際怎麼樣。